INFO-ATARI16 Digest Mon, 6 Nov 89 Volume 89 : Issue 612 Today's Topics: am I a DA archive sites Congratulations (was: GEMDOS Extended Argument Spec) GEMDOS Extended Argument Spec (LONG) HARD DISK UTILITIES Hard Drive Problems Has anyone heard of TCOS database? Laserjets and the ST Memory upgrade affects performance? PC emulator info request Trying to read an Atari St Gem-Dos disk on a Mac SE using FD/HD XLISP 2.0 ---------------------------------------------------------------------- Date: 6 Nov 89 19:40:55 GMT From: imagen!atari!kbad@ucbvax.Berkeley.EDU (Ken Badertscher) Subject: am I a DA UO04@DDAGSI3.BITNET (H.Friedrich Kammer) writes: | It is right that the startup code should | do the right thing (mshrink or not), but there are startup codes | available (e.g. APPACC.A) which ensure the correct startup in both | cases. The problem is not whether the startup code should Mshrink or not. The problem is finding the basepage address. The method used by all the startup code I have seen uses the text base address minus 256 as the basepage address, and that is not the right way to find it. | The other problem (find out the way the program is invoked) | can be solved simply by using the AES-function shel_read, which | returns a pointer to the string containing the program name Shel_read doesn't help if you are run from a command line shell which doesn't launch programs using shel_write. This is another example of problems caused by ST programs having to live in two different worlds, the worlds of GEM and GEMDOS. Allowing the startup code to use A0 to find the basepage address is our way of making it a little easier for programs to live in both worlds. -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari R&D System Software Engine / | \ #include ------------------------------ Date: 6 Nov 89 21:16:50 GMT From: scott@xanth.cs.odu.edu (Scott Yelich) Subject: archive sites In article <1707@quiche.cs.mcgill.ca> depeche@quiche.cs.mcgill.ca (Sam Alan EZUST) writes: > does anyone know > 1] why xanth's atari directory is empty? because the people here who would set-up automatic archiving for the network all own amigas. I am working on some sort of archive site here.... most likely, it will be mail based and be batched out on the weekends... no promises... -- ----------------------------------------------------------------------------- Scott D. Yelich scott@cs.odu.edu [128.82.8.1] After he pushed me off the cliff, he asked me, as I fell, ``Why'd you jump?'' ----------------------------------------------------------------------------- ------------------------------ Date: 6 Nov 89 06:34:13 GMT From: nis!pwcs!stag!daemon@UMN-CS.CS.UMN.EDU (Dale Schumacher) Subject: Congratulations (was: GEMDOS Extended Argument Spec) [buchanan@grads.cs.ubc.ca (John Buchanan) writes...] > In article <1763@atari.UUCP> kbad@atari.UUCP (Ken Badertscher) writes: >> >>GEMDOS EXTENDED ARGUMENT (ARGV) SPECIFICATION >> >>Introduction > > > This is what we have being waiting for. Nice to hear an OFFICIAL > word about this whole mess. > > > WELL DONE ATARI. Humph. It IS nice to have an OFFICIAL statement on a subject that should have been settled YEARS ago, but what a statement it is! I guess ATARI figured that if they waiting long enough, and THEN posted a "standard", we would forget all the good arguments AGAINST this particular form of brain-damage. This "new" extended argument spec is Mark Williams form, with a thin (optional) layer of veneer on it, even after it was flatly stated that the MWC form WOULD NOT BE ACCEPTED due to the ways in which is was broken. It appears that politics has won out over technical merit once again. I don't expect that Atari will change their mind on this issue (without taking another YEAR to post an answer), but I will include some information on how the MWC form (at that time) and Atari's "new standard" are broken. Remember, one of the design goals of this standard is to be upward compatible with naive programs. David Parsons wrote (in March): | Say, for example, that I call the teeny-shell from a program that uses | MWC arguments; Teeny-shell will get ARGV=<0>ARG0<0>...<0><0>. | which will parse to at least one valid environment variable - ARGV=ARG0. | If any of the arguments I passed into the teeny-shell have `=' in them, | they, too, will get converted into valid environment variables. (if I | do `tsh -i PATH=g:,c:\bin,c:\games,. some-initial-command', for example.) | | And if this child (the one who doesn't grok the MWC `standard') does | a putenv() or two, it will end up (most likely) putting new environment | variables at the end of the arglist, after the corpse of the argument-list. | | The diddles to the length of the cmdline tail will prevent children from | incorrectly reading the environment, but there will still be this | collection of garbage left orphaned in the environment. And if the teeny- | shell calls another process that groks MWC args, which then forks off another | process, well, then that orphan will see the first ARGV= value, which is | now being treated as a valid environment variable, and get stuck with the | fun prospect of trying to figure out if it is, indeed, the start of the | argument list or if it's something else. | Say, for example, that I call the teeny-shell from a program that uses | MWC arguments; Teeny-shell will get ARGV=<0>ARG0<0>...<0><0>. | which will parse to at least one valid environment variable - ARGV=ARG0. | If any of the arguments I passed into the teeny-shell have `=' in them, | they, too, will get converted into valid environment variables. (if I | do `tsh -i PATH=g:,c:\bin,c:\games,. some-initial-command', for example.) | | And if this child (the one who doesn't grok the MWC `standard') does | a putenv() or two, it will end up (most likely) putting new environment | variables at the end of the arglist, after the corpse of the argument-list. | | The diddles to the length of the cmdline tail will prevent children from | incorrectly reading the environment, but there will still be this | collection of garbage left orphaned in the environment. And if the teeny- | shell calls another process that groks MWC args, which then forks off another | process, well, then that orphan will see the first ARGV= value, which is | now being treated as a valid environment variable, and get stuck with the | fun prospect of trying to figure out if it is, indeed, the start of the | argument list or if it's something else. | Say, for example, that I call the teeny-shell from a program that uses | MWC arguments; Teeny-shell will get ARGV=<0>ARG0<0>...<0><0>. | which will parse to at least one valid environment variable - ARGV=ARG0. | If any of the arguments I passed into the teeny-shell have `=' in them, | they, too, will get converted into valid environment variables. (if I | do `tsh -i PATH=g:,c:\bin,c:\games,. some-initial-command', for example.) | | And if this child (the one who doesn't grok the MWC `standard') does | a putenv() or two, it will end up (most likely) putting new environment | variables at the end of the arglist, after the corpse of the argument-list. | | The diddles to the length of the cmdline tail will prevent children from | incorrectly reading the environment, but there will still be this | collection of garbage left orphaned in the environment. And if the teeny- | shell calls another process that groks MWC args, which then forks off another | process, well, then that orphan will see the first ARGV= value, which is | now being treated as a valid environment variable, and get stuck with the | fun prospect of trying to figure out if it is, indeed, the start of the | argument list or if it's something else. The major problem here is that the NUL separated pieces of the extended argument list appear to the naive program AS ENVIRONMENT VARIABLES and my be reshuffled (some shells may SORT them) by that program, modified and passed on to a program which comforms to this "standard". Now what happens when this conforming program finds "ARGV=" right up at the front of the (sorted) environment and THROWS AWAY THE WHOLE ENVIRONMENT. It does this because the command line length is not the magic value, thus the "ARGV=" list is not from it's parent, but is still used to terminate the environment! \\ / Dale Schumacher 399 Beacon Ave. \\ / (alias: Dalnefre') St. Paul, MN 55104-3527 >< ...umn-cs!midgard.mn.org!syntel!dal United States of America / \\ "What is wanted is not the will to believe, but the will to find out, / \\ which is the exact opposite." -Bertrand Russell ------------------------------ Date: 6 Nov 89 19:53:06 GMT From: imagen!atari!kbad@ucbvax.Berkeley.EDU (Ken Badertscher) Subject: GEMDOS Extended Argument Spec (LONG) klute%trillian@laura.UUCP writes: | Nice to get that document! I admit I have not read it yet, only | searched for the word "official" - and failed. Comments? Yes, it's official. I guess I should have put a big header at the top reading: "THIS IS THE OFFICIAL WORD FROM ATARI ON HOW TO DO THIS ARGUMENT STUFF" I just wanted to release it to the public so it would get widely used. -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari R&D System Software Engine / | \ #include ------------------------------ Date: 6 Nov 89 18:12:58 GMT From: unisoft!bdt!david@ucbvax.Berkeley.EDU (David Beckemeyer) Subject: HARD DISK UTILITIES What exactly was the "supply problem" your dealer is talking about? We have all the HARD DISK SENTRYS you could want ready to ship. Your dealer could call us directly if his/her distributor is out of stock: (415) 452-1129. -- David Beckemeyer (david@bdt.UUCP) | "Lester Moore - Four slugs from a .44 Beckemeyer Development Tools | no Les, no more." 478 Santa Clara Ave. Oakland, CA 94610 | - Headstone at Boot Hill UUCP: ?uunet,ucbvax?!unisoft!bdt!david | Tombstone, AZ ------------------------------ Date: 6 Nov 89 19:40:44 GMT From: shlump.nac.dec.com!engage.enet.dec.com!oldtmr!wallace@decuac.dec.com (Ray Wallace) Subject: Hard Drive Problems In article <1416@blackbird.afit.af.mil>, @falcon.afit.af.mil (Gene Place) writes... >I was in the process of moving files around and moved some .ACC files onto >the root drive of my hard disk. I reset my system to check how much memory >those .ACCs had been taking up, but now every time my disk tries to >boot, it causes a system reset. I'm working on a 1040ST with a Haba 10 >hard disk. Any ideas on how to get my drive to talk to me again? Use DCformat to create a bootable floppy (a floppy with boot code on it), DCformat has a button to click on to do this though I forget exactly what the button says. Place this boot floppy in drive A, turn the computer OFF, wait about five seconds, turn computer on. At this point the ST will BOOT the floppy not the HD, all you have to do now is to run your hard disk boot program (ICDBOOT.PRG et.al.), install a drive Icon for C:, open up drive C: and delete the offending .ACCs. Don't forget to keep the floppy around for next time (yes there will be a next time :-) --- Ray Wallace (INTERNET,UUCP) wallace@oldtmr.enet.dec.com (UUCP) ...!decwrl!oldtmr.enet!wallace (INTERNET) wallace%oldtmr.enet@decwrl.dec.com --- ------------------------------ Date: 6 Nov 89 18:56:49 GMT From: cs.utexas.edu!usc!sdsu!crash!canada@tut.cis.ohio-state.edu (Diane Barlow Close) Subject: Has anyone heard of TCOS database? I have discovered a wonderful ``index card and button'' type database called TCOS. It's public domain, and supposed to be from Britain, but the documentation that comes with it gives only a name of a person to contact but *no address*! I want to send in my $$ and my suggestions for enhancements. Perhaps someone else has heard of this program and knows more about it? Here's the info: TCOS version 1.2 Perfect Evolution 1989 Matthew P. Aubury Can anyone supply me with more information? Is there a newer version of the program available anywhere? -- Diane Barlow Close ?nosc, ucsd?!crash!canada canada@crash.cts.com Free Canada -- Trade Mulroney ------------------------------ Date: 6 Nov 89 18:25:16 GMT From: fozzy!hendrick@uunet.uu.net (Bill Hendricks) Subject: Laserjets and the ST I recently asked for info from people who had the new HP Laserjet II-P, and got no responses. OK, so it's a little soon to expect lotsa people to have a II-P. Let me rephrase the question: Can anyone out there give me some idea of how long it takes to print a full 8.5 X 11 page of 300 dpi graphics (like with _Calamus_ :-)) on an HP Laserjet (of any kind)? My local Atari dealer says that the "sale" price on the SLM-804 of $1299 might have already gone by, leaving the $1999 price again. (No way I want to pay that kind of $$$ !!) Thanks in advance for any/all info. Regards, Bill ------------------------------ Date: 6 Nov 89 20:04:21 GMT From: imagen!atari!kbad@ucbvax.Berkeley.EDU (Ken Badertscher) Subject: Memory upgrade affects performance? dmk@cbnewsi.ATT.COM (daniel.m.kuster..jr) writes: | The thing I don't understand is that the computer takes at least | 4 times as long to boot (possibly longer). As numerous people have pointed out, the operating system clears all of free memory for each program before loading. Not only that, but the original ROM TOS does this slowly. Also as some have pointed out, one solution is to use Pinhead, which takes control of program loading when it sees GEMDOS clearing memory, and only clears as much memory as the program needs. IMHO, a better solution would be for you to get the Rainbow TOS upgrade. This allows you to speed up program startup selectively (some programs insist on having all of memory cleared), AND it has lots of other benefits as well. -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari R&D System Software Engine / | \ #include ------------------------------ Date: Mon, 6 Nov 89 13:14 EDT From: Subject: PC emulator info request Well I'm ready to take the PC plunge, No I don't mean I'm giving up on my ST. I want to buy a PC emulator, the only one I really know about is PC-Ditto II. Could someone send me any information on this or other PC packages. Things like Cost Hardware Speed Compatibility etc... Any info at all would be greatly appreciated!!!! Thanks in advance Bob ------------------------------ Date: 6 Nov 89 20:42:52 GMT From: crdgw1!minerva!oplinger@uunet.uu.net (B. S. Oplinger) Subject: Trying to read an Atari St Gem-Dos disk on a Mac SE using FD/HD In article <1989Nov5.193654.3552@agate.berkeley.edu> c60b2-cc@garnet.berkeley.edu (Axel K. Olmos) writes: >FDHD to ST conversion. By Axel K. Olmos > A MFS (Not HFS!) Partition on your hard disk with 720K free. > OR > A MFS formatted double sided disk. (Note, Spectre double >sided disk are usually formatted HFS, you will need a special >program to do this.) You can use the formating program from your old Magic Sac or the Double Click formatter/coppier program (forget the name). > 2. Run Transverter. Put the MSDOS disk in drive A and >set the ST source drive to A:. Set the destination Mac drive >to where ever your MFS disk or partition is. When it asks you if >you want to strip linefeeds, say NO. When it asks for creator >name and type for both, say "SIT!". (No quotes). (I have heard reports >that if your ST is one meg or less, you will have trouble transverting >large files) Transverter reads the entire disk into memory. On a 1Meg machine there is only about 630K free after the transverter program is loaded so that is the maximum file size. Note: you can fill up the disk with files, the 630K rule is for any file, because transverter only works one file at a time. >P.S. I think if you format a disk on the Mac as MSDOS, then put it in >an ST, and copy ST files to it, then put it back in the mac, you might >be able to port ST files to the Mac... Yes, but it isn't quite that simple. After you used Apple file exchange and have the file on a MAC (BTW Stuffit files work best), use ResEdit (1.2 or later) to open up the file. ResEdit will give you a warning along the line of "the file does not have a resource fork and opening the file will create one." Pick yes/open/go ahead (whaterver the positive choice is). Now close the file. All you wanted to do is make a resource fork for the file. Now use a file maintenace utility and set the file type and owner to "SIT!", again no quotes or use ResEdit (sorry I don't use resedit for this and cannot give directions). brian oplinger@crd.ge.com -- <#include standard.disclaimer> ------------------------------ Date: 6 Nov 89 14:58:16 GMT From: Teknowledge.COM!unix!excelan!leadsv!laic!trimble@beaver.cs.washington.edu (Gary Trimble) Subject: XLISP 2.0 I have been unsucessfully trying to get the sources for Dave Betz's XLISP 2.0. If you have these or know where I can find them, please respond via email. Thanks! ------------------------------ End of INFO-ATARI16 Digest V89 Issue #612 ***************************************** =========================================================================